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Ep O- Munich 

'. *' i*ITLE OF THE INVENTION 20 

l&Dez.2088 

IP Address Management 

5 FIELD OF THE INVENTION 

The present invention relates to an address management in 
networks in which addresses are allocated dynamically from a 
limited address pool. In particular, the invention relates to 
10 managing addresses in an access network assigning addresses to 
users of an IP network. 

BACKGROUND OF THE INVENTION 

15 IP (Internet Protocol) addresses, such as IPv4 (IP version 4) 
addresses are a limited resource that has to be recycled: when 
a user loses a connection, the address will be assigned to a 
new user. In case the old user has disconnected brutally, i.e. 
a connection is lost without having a chance to inform 

20 correspondent nodes about the connection loss, the address of 
the old user may have been reassigned to a new user before all 
of the old user's sessions have expired. As a result, the new 
user may receive packets that belong to the old user of the 
IPv4 address. For example, such connection losses are caused 

25 by the old user moving out of a coverage area or running out 
of battery. 

Although the new user has not asked for these packets, he has 
to pay for receiving them anyway. This "overbilling" attack 
30 which happens e.g. in GPRS (General Packet Radio Service) and 
3G (Third Generation) networks is a security incident. 

Typically a stateful FW (FireWall) is used to stop incoming 
unsolicited packets. However, in the case of brutal disconnect 
35 the FW states ("pinholes") are not reset, because the FW has 
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not been notified about the loss of the connection. Both TCP 
(Transport Control Protocol) and UDP (User Datagram Protocol) 
packets get through, if they match an old pinhole. 

5 The time to wait until an address can be reassigned, i.e. a 
"cooling" time, varies, because there are no standard values 
for either TCP retry limit or UDP soft state lifetime. 
Typically TCP gives up only after several minutes of trying 
(depending on implementation) , and UDP soft states live at 

10 least one minute (depending on FW settings) . Sessions can also 
end if a NAT (Network Address (and Port) Translator) along the 
path resets an address-port binding, because it has not been 
used for some predefined time. Details about NAT can be found 
in P. Srisuresh et al.: "Traditional IP Network Address 

15 Translator (Traditional NAT)", Network Working Group, RFC 

3022, January 2001. All of the above times can be different, 
and can be configured at different sites. 

For example, an address cooling mechanism using IPv6 is 
20 described in applicant's WO 01/93540. However, previous 

suggestions of address cooling mechanisms have used only an 
estimate of the longest possible cooling period before an 
address can be reactivated, and used that to estimate the size 
of the required cooling queue. Such size may be uncomfortably 
25 large for IPv4. 

Another suggestion is that the FW should read ICMP (Internet 
Control Message Protocol) error notifications transmitted to 
the senders, and close remaining pinholes to released 
30 addresses as described in applicant's US 60/479509. More 
details about ICMP are described by J. Postel: "Internet 
Control Message Protocol", Network Working Group, RFC 792, 
September 1981. 
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Alternatively it has been suggested to use two FWs, one at Gn 
side of a GGSN (GPRS Gateway Serving Node) detecting PDP 
(Packet Data Protocol) context terminations, and another on 
the Gi side stopping packets to addresses that the first FW 

5 reports as unused. This solution is very expensive, because it 

i, ■ 

requires installing FWs in many places. Also it is limited to 
GPRS and 3G networks. 

Moreover, the FW suggestions may not help if a free address 
10 pool is small, and a new user happens to activate the same 
service that the old user had running. In this case the new 
user opens a pinhole that again lets the old user's session 
through . 

15 SUMMARY OF THE INVENTION 

It is an object of the invention to improve reassigning IP 
addresses to users in order to avoid extra packets for the 
users resulting e.g. in the overbilling attack. 

20 

According to an aspect of the invention, this object is 
achieved by a network device according to claim 1 and a method 
according to claim 14. 

25 According to another aspect of the invention, the above object 
is achieved by a network device according to claim 9 and a 
method according to claim 15. 

According to a further aspect of the invention, the above 
30 object is achieved by a system according to claim 13. , 

The invention may also be provided by a computer program 
product comprising software code portions to be executed by a 
computer, microprocessor or the like. 

35 
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According to the invention, the size of a cooling queue will 
depend on averages , not maximum, because a cooling period of 
each address will adapt to stack implementations of 
correspondent nodes of an old user. Troublesome addresses 
5 connected to long-living sessions may be sent back to the end 
of the cooling queue several times. With the invention the 
number of cooling addresses can be reduced significantly, 
because a free address pool needs only a few "cold" addresses 
that rise quickly to the front of the queue. 

10 

Furthermore, the solution according to the invention is 
independent of FW and NAT locations and timers. 

Moreover, the cooling method of the invention can be extended 
15 to DHCP- (Dynamic Host Configuration Protocol) assigned 
addresses. Therefore the invention works with any access 
network. 

In the following the present invention will be described by 
20 way of preferred embodiments thereof taking into account the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 Fig. 1 shows an address management according to the invention 
in case it is detected that a packet has been sent to a 
released address. 

Fig. 2 shows an address management according to the invention 
30 in case it is detected that an address has been released. 

Fig. 3 shows an address management according to the invention 
in case an address out of released addresses is to be 
reassigned. 

35 
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Fig. 4 shows a schematic block diagram illustrating an address 
management entity according to an embodiment of the invention. 

Fig. 5 shows a schematic block diagram illustrating an address 
5 management entity according to another embodiment of the 
invention . 

DESCRIPTION OF THE INVENTION 

10 Figs. 1, 2 and 3 show an address management scheme according 
to the invention. An address management entity shown in these 
figures is responsible for assigning addresses to IP network 
users and comprises a cooling queue 10 for holding released 
addresses such as released IPv4 addresses. An address release 

15 may result from a connection loss which may be due to a brutal 
disconnect of a user. 

The upper part of Fig. 1 shows the cooling queue 10 holding 
released addresses Al to An. In case the address management 

20 entity detects that a packet has been addressed to a released 
address held in the cooling queue 10, such as to the released 
address A4, the released address A4 is shifted to the end of 
the cooling queue 10. The result of this cooling queue update 
is shown in the lower part of Fig. 1. As shown in the lower 

25 part of Fig. 1, the released addresses A5 to An have moved 

forward by one place to the front of the cooling queue 10 and 
the released address A4 is placed at the end of the cooling 
queue 10. 

30 The upper part of Fig. 2 shows like the upper part of Fig. 1 
the cooling queue 10 holding the released addresses Al to An. 
In case the address management entity detects that an address 
of a user has been released, such as an address An+1, the 
released address An+1 is added to the end of the cooling 
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queue. The result of this cooling queue update is shown in the 
lower part of Fig. 2. 

The upper part of Fig. 3 shows like the upper part of Figs. 1 
5 and 2 the cooling queue 10 holding the released addresses Al 
to An. In case an address out of the released addresses held 
in the cooling queue 10 is to be reassigned, e.g. because a 
free address pool is empty, the address at the beginning of 
the cooling queue is taken out as address to be reassigned. 
10 According to Fig. 3, since the address at the beginning of the 
cooling queue is the address Al, the address Al is taken from 
the cooling queue 10 for reassigning. The result of this 
reassignment is shown in the lower part of Fig. 3. 

15 As described above, the address management entity or Address 
Manager (AM) that is responsible for assigning addresses lets 
a released address "cool" until no packets to an old user 
having had the released address before are received. The 
cooling mechanism is adaptive: it uses the least-recently-used 

20 cooling queue 10. Released addresses go to the end of the 

cooling queue 10. In case e.g. a free address pool is empty,, 
the first address in the cooling queue 10 (Al according to 
Fig. 3) gets assigned to a next new user. 

25 The idea is that each time an address already in the cooling 

queue 10 receives a packet, the address is returned to the end 
of the cooling queue 10. In addition, an error message (e.g. 
ICMP "not reachable") may be returned to a sender or source of 
the packet, e.g. a correspondent node of the old user, to 

30 inform it that sessions to the address are broken. 

In case the address management entity is placed in a data 
path, like a GGSN, it can handle the queue internally. In 
other words, the address management entity may detect that a 
35 packet has been addressed to a released address held in the 
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cooling queue 10 by receiving a packet addressed to the 
released address. Furthermore, the address management entity 
may detect that an address of a user has been released by 
detecting a loss of a connection which releases its address. 

5 

Fig, 4 shows an embodiment of the invention in which the 
address management entity or address manager is in the data 
path, i.e., the address manager and an AR (Access Router) are 
integrated like in a GGSN that manages its own address pool. 
10 In Fig. 4, the integrated address manager and access router 
block 30 is located in an access network, e.g. an IP based 
access network, providing access to an IP network for a user. 
The block 30 comprises the cooling queue 10. 

15 In case the functions of the address management entity and 
those of the access router are combined as shown in Fig. 4, 
the loss of a connection releases its address, which is added 
to the end of the cooling queue 10 as shown in Fig 2. A next 
released address goes behind it, etc. But each time a packet 

20 arrives to a cooling address held in the cooling queue 10, the 
address is again returned to the end as shown in Fig. 1, and 
an ICMP error notification may be sent to the source of the 
packet by the integrated block 30. 

25 Returning a released address repeats until all sessions that 

are bound to the released address have expired. After that the 
address can advance to the first position in the queue, and 
can then be assigned to a new user. 

30 In case the address management entity and the data path are 
separated like e.g. in DHCP (Dynamic Host Configuration 
Protocol) , an access router along the data path of the old 
user notifies the address management entity about lost 
connections, and also sends copies of error messages to the 

35 address management entity, the error messages notifying 
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packets sent to unused addresses. The cooling queue is in the 
address management part. For details about DHCP it is referred 
to S. Alexander, R. Droms : "DHCP Options and BOOTP Vendor 
Extensions", Network Working Group, RFC 2132, March 1997. 

5 

In other words, in case the address management entity is not 
located in the data path of the old user, the address 
management entity may detect that a packet has been addressed 
to a released address held in the cooling queue 10 by 
10 receiving an error notification indicating an unused address. 
Furthermore, the address management entity may detect that an 
address of a user has been released by receiving a 
notification thereon. 

15 In case the access router in the data path receives a packet 
addressed to an unused address it sends an error notification 
to the address management entity, the error notification 
indicating, the unused address. In addition, the access router 
may also send an error notification to a source of the packet. 

20 Moreover, in case the access router detects a loss of a 

connection which releases its address, it sends a notification 
about the released and now unused address to the address 
management entity . 

25 Fig. 5 shows a separated access router 42 and address 

management entity or address manager 41. The address manager 
41 comprises the cooling queue 10. The access router 42 is 
located in the data path of the old user. 

30 When the access router 42 loses a connection, it notifies the 
address manager 41 about the address that can be released. The 
address manager 41 puts the address in the cooling queue 10 as 
described above in connection with Fig. 2. If the access 
router 42 later receives a packet to an unused, i.e. released 

35 address, it sends an error notification to the address manager 
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41 , which pushes the address to the end of the cooling queue 
10 as shown in Fig. 1. The access router 42 may also send an 
ICMP error as it is done in the integrated case above. 

5 The message from the access router 42 to the address manager 
41 to release an address can be RADIUS (Remote Authentication 
Dial-In User Service 'Accounting Stop 1 . The access router - 
address manager error notification protocol can be ICMP, but 
also a proprietary protocol is possible. Details about RADIUS 
10 can be found in C. Rigney et al.: "Remote Authentication Dial 
In User Service (RADIUS) " , Network Working Group, RFC 2865, 
June 2000, and C. Rigney: "RADIUS Accounting", Network Working 
Group, RFC 2866, June 2000. 

15 The invention has been explained using a single LRU (Least 

Recently Used) cooling queue 10 per address range. However, it 
is possible to classify a released address into a group out of 
at least two address groups, each address group having its own 
cooling queue holding released addresses, and to add the 

20 released address to the end of the queue of the classified 
group, the queues being given a priority order for re- 
assigning the released addresses held in the queues. 

In other words, it is possible to classify the addresses as 
25 being "troubled", or connected to misbehaving nodes, e.g. 

those that ignore ICMP errors. For example, an address may be 
classified as being troubled in case transmission attempts for 
this address continue in spite of an ICMP error report, or the 
number of packets sent to this address exceeds a configurable 
30 limit. This classification may be carried out by the address 
management entity such as the integrated address manager and 
access router 30 or the address manager 41. Troubled addresses 
may be sent to a special queue by the address management 
entity which special queue is used for reassigning only when 
35 the normal queue (i.e. the cooling queue 10) is empty. 
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Addresses in the queues given a higher priority than the 
special queue for "troubled" addresses will pass the troubled 
addresses. This way it is possible to avoid a situation where 
a non-cooled address gets reassigned, because it has not been 
5 accessed for some time, and during that time it has reached 
the front of the cooling queue 10. 

It is to be understood that the above description is 
illustrative of the invention and is not to be construed as 
10 limiting the invention. Various modifications and applications 
may occur to those skilled in the art without departing from 
the true spirit and scope of the invention as defined by the 
appended claims. 
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CLAIMS ; , 2° 

laOez.2003 

1. A network device for managing addresses to be assigned to 
users of an IP network, the network node comprising: 

at least one queue for holding released addresses, 
the network device being arranged to: 

detect that a packet has been addressed to a released 
address held in the at least one queue; and 

return the held address to which the packet has been 
addressed to the end of the at least one queue. 

2. The network device according to claim 1, further being 
arranged to: 

detect that an address of a user has been released; and 
add the released address to the end of the at least one 
queue . 

3. The network device according to claim 2, further being 
arranged to: 

classify the released address into a group out of at least 
two address groups, each address group having its own queue 
holding released addresses; and 

add the released address to the end of the queue of the 
classified group, the queues being given a priority order for 
re-assigning the released addresses held in the queues. 

4. The network device according to any one of claims 1 to 3, 
further being arranged to: 

upon detection that a packet has been addressed to a 
released address held in the at least one queue, send an error 
notification to a source of the packet. 

5. The network device according to any one of claims 1 to 4, 
wherein the network device is arranged to detect that a packet 
has been addressed to a released address held in the at least 
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one queue by receiving a packet addressed to the released 
address . 



6. The network device according to any one of claims 2 to 5, 
5 wherein the network device is arranged to detect that an 

address of a user has been released by detecting a loss of a 
connection which releases its address. 

7. The network device according to any one of claims 1 to 3, 

10 wherein the network device is arranged to detect that a packet 
has been addressed to a released address held in the at least 
one queue by receiving an error notification indicating an 
unused address. 

15 8. The network device according to claims 2, 3 or 7, wherein 
the network device is arranged to detect that an address of a 
user has been released by receiving a notification thereon. 

9. A network device for forwarding IP data packets, the 
20 network device being arranged to: 

receive a packet addressed to an unused address; and 
send an error notification to a network node for managing 

addresses, the error notification indicating the unused 

address . 

25 

10. The network device according to claim 9, wherein the error 
notification causes returning a released address held in a 
queue and corresponding -to the unused address to the end of 
the queue, the queue holding released addresses. 

30 

11. The network device according to claim 9 or 10, further 
being arranged to: 

detect a loss of a connection which releases its address; 

and 
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send a notification about the released address to the 
network node for managing addresses. 

12. The network device according to any one of claims 9 to 11, 
further being arranged to: 

upon receipt of the packet addressed to the unused 
address, send an error notification to a source of the packet. 

13. A system for managing addresses to be assigned to users of 
an IP network, comprising: 

a network node for managing addresses according to any one 

of claims 1 to 3, 7 and 8; and 

a network node for forwarding IP data packets according to 

any one of claims 9 to 12. /' 

14. A method of managing addresses to be assigned to users of 
an IP network, the method comprising the steps of: 

detecting that a packet has been addressed to a released 
address held in a queue holding released addresses; and 

returning the held address to which the packet has been, 
addressed to the end of the queue. 

15. A method of forwarding IP data packets, the method 
comprising the steps of: 

receiving a packet addressed to an unused address; and 
sending an error notification to a network node for 

managing addresses, the error notification indicating the 

unused address. 

16. The method according to claim 15, wherein the error 
notification causes returning a released address held in a 
queue and corresponding to the unused address to the end of 
the queue, the queue holding released addresses. 
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17. A computer program product comprising software code * 
portions for performing the steps of any one of claims 14 to 
16, when said product is run on an computer. 

5 18. The computer program product according to claim 17, 

further comprising a computer-readable medium on which the 
software code portions are stored. 

19. The computer program product according to claim 17 , 
10 wherein the computer program product is directly loadable into 
an internal memory of the computer. 
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20 

abstract : J 6, Dez. 2003 

Managing addresses to be assigned to users of an IP network i 
described, in which it is detected that a packet has been 
addressed to a released address held in a queue for holding 
released addresses, and the held address to which the packet 
has been addressed is returned to the end of the queue. 
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